在第一天的時候，我提過這次鐵人賽的目的是讓每個人「都瞭解架構師是什麼」。從這三十天的過程當中我相信大家應該都能看出，架構師在軟體開發這條船上扮演的角色是舵手，不是船長、也不是水手。

軟體開發的前半段時間是設計環節，從系統設計到資料庫選型等充斥一連串的選擇，在這諸多技術決策中，架構師有責任根據各種主觀、客觀條件作出當下最能接受的抉擇。正如同在波濤洶湧的海面上，當船長指明目的後，要如何根據風向、海象調整方向往目標邁進這是架構師的任務。

在軟體開發的後半段時間中，實際開發是重中之重。事實上，架構師通常不直接參與寫程式的過程，但這並不代表這段期間架構師就無所事事了。在結隊編程(pair programming)中，有兩個角色：領航員和駕駛員，架構師此時依然是指引方向的存在，提示程式碼的缺陷、找出效能低落的邏輯甚至必須解釋如何「為了未來而寫」。

是的，程式碼並不是能工作就結束了，更多時候我們的程式碼是為了被維護而存在的。如何建構出一個容易維護、彼此能順暢合作的程式架構，這也同樣是架構師的職責範圍。所以領域驅動設計、測試驅動設計和各種應用模式都需要瞭如指掌。

讀懂這三十篇就是合格的架構師嗎？

我得要說，光是這三十天其實並不足以完整講述成為架構師以後「要做什麼」，正如我第一天說的，架構師在每個組織都有不同的角色定位，因此在技能樹的選擇上不一定會完全相同。

即使是選擇成為一個賢者，依然可以在火系魔法和冰系魔法中投資技能點數。但人的一生能點的技能有限，因此如果想成為架構師，如何有效分配技能就是一個重要課題。

就以我來說，我現在所扮演的角色與之前組織需要的技能完全不同，而我現在在做的事有一大半都沒列在這三十天內(明年繼續參賽就能羅列了)。那我是如何分配有限的時間把技能樹點完的呢？

其實，要能夠在各個組織轉換有個很重要的心態，必須要多「觀察」。在一個組織中，也許有些系統、有些部門是你完全不會有交集的，但秉持學習的心態，還是得要從中吸取無論經驗、技能或知識。當你認識更多範式(paradigm)、聽過更多技術決策、參與更多技術選型後，無形之中你也會具備相應的經驗值。

這也意味著你有了滿手的技能點數，只是還沒點下去而已，那麼無論之後需要隕石術還是暴風雪，都可以游刃有餘的點滿。

想要成為架構師，有沒有速成武功秘笈？

這我相信是多數人心中的疑問。這麼多技能需要學習，但又不可能像無頭蒼蠅般亂試，有沒有一條比較容易走的康莊大道？

嘿，還真的有。

如果你已經是一個資深軟體工程師了，那麼我相信你已經具備某些程式語言的專長、資料儲存的專長並且是某個領域的專家了，接下來需要的就是更廣的視野。

首先我推薦這本書。

裡面包含了各種軟體開發的心態和應該具備的正確思維。接著為了正確建構良好的軟體架構，你會需要這本。

有了這兩本書，你可以知道軟體開發的各種面向，並且知道該如何補足不足的部分。

但架構師還必須對各種資料儲存和資料架構具備正確認知，因此需要一本書能夠涵蓋大部分需要用到的資料儲存，並且提供正確的範式。

最後，當我們都具備軟體開發的認知和資料儲存的通透理解，我們需要知道系統設計的各種決策和考量。因此需要一個軟體架構的綜合全覽。

以及他的下集。

能夠將這五本書讀透，我相信你已經擁有成為架構師的門票了。但讀透指的不僅僅只有把書看完而已，而是能夠根據書中的內容融入自己的日常，真正內化成為自己的知識。

這個過程並不容易，但若是想成為架構師，那麼「知識內化」這個技能我推薦無論如何都一定要投資技能點數，不然永遠都只能紙上談兵而已，那不是架構師，那是吹牛大師。

若是你尚未成為一個資深軟體工程師，那麼就先努力變得資深吧！千萬不要越級打怪。挑戰高等級的怪物是指雖然等級有一段差距，但你知道可以靠著操作彌補回來，可如果是一個初級軟體工程師就想直接成為架構師，這是在堆屍不是在打怪。

最後我想說的是

如果這三十天的內容對你來說猶如一塊蛋糕，而且你也很喜歡這樣的日常，那麼我得要告訴你：

We are hiring!

歡迎與我聯繫。若是有想要探討的學術問題，也可以找我聊聊。